<html>
<head><meta charset="utf-8"><title>rust &lt;-&gt; wasm &lt;-&gt; VM networking · general · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/index.html">general</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html">rust &lt;-&gt; wasm &lt;-&gt; VM networking</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="209957487"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/209957487" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> ender <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#209957487">(Sep 14 2020 at 00:57)</a>:</h4>
<p>I know that Rust can compile to WASM and WASM is sometimes described as a VM or VM like. Can anyone give me more resources on WASM as a VM? I've been trying to find the right way to ask this and the right place to do it.</p>
<p>I was researching the capabilities of WASM "VMs" and Emscripten docs remarked that when you compile to WASM through emscripten, it is <a href="https://emscripten.org/docs/porting/networking.html">not possible</a> to emulate networking capabilities, although it possible to emulate a filesystem quite easily. </p>
<p>How could you emulate networking capabilities with Rust -&gt; WASM?</p>



<a name="209969339"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/209969339" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#209969339">(Sep 14 2020 at 06:39)</a>:</h4>
<p><span class="user-mention" data-user-id="341972">@ender</span> So, it might sound like a silly question at first but... how much do you know about JavaScript? because the basic premise of WASM is "what if we had an assembly-like language where JavaScript goes?" Actually first it was "how do we turn JS into asm?" So if you know about the JS runtimes and how they are sandboxed and et cetera, then there's actually a pretty smooth mapping from them to WASM as a concept.</p>



<a name="209969760"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/209969760" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#209969760">(Sep 14 2020 at 06:46)</a>:</h4>
<p>In browsers, WASM is often executed by the same engine as JS, and thus can transfer control to JS and back. This is why browser WASM is usually not multithreaded... for all the same reasons JS is not! And part of the premise of JS is that it is <em>sandboxed</em>. At least somewhat. It cannot do things the overarching environment, which it does not directly control, does not enable. WASM must be given to a program that is prepared to execute it, and that program determines WASM's capabilities in terms of things like doing syscalls and such. However, a standard interface called "WebAssembly System Interface" for sandboxed-yet-outwardly-interfacing WASM is being developed... that's basically your Node. And right now, in a browser, you can use various bindings that yield to JS and do AJAX calls.</p>



<a name="209969887"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/209969887" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Laurențiu <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#209969887">(Sep 14 2020 at 06:49)</a>:</h4>
<p>WASM running in browser can do exactly what JS can do because it has to pass through JS to interact with the outside world, other than that it's compute-only, without interaction. There are some proposals to allow WASM to interact with the runtime, so you'll be able to call DOM APIs directly from there, but in the end you're still limited by what the platform allows you to do. In a browser, that means <code>fetch</code>.</p>



<a name="209969978"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/209969978" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Laurențiu <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#209969978">(Sep 14 2020 at 06:51)</a>:</h4>
<p><code>emscripten</code> is mostly concerned about emulating POSIX or C APIs like <code>connect</code> or <code>fopen</code> when running in the browser. You can do the latter by using local storage, but there's no support for sockets (though I imagine someone has written a WebSockets proxy for that).</p>



<a name="209999193"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/209999193" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#209999193">(Sep 14 2020 at 12:50)</a>:</h4>
<p>You might want to look at:</p>
<ul>
<li><a href="https://wasi.dev/">https://wasi.dev/</a></li>
<li><a href="https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/">https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/</a></li>
</ul>



<a name="210079140"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210079140" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sam Sartor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210079140">(Sep 15 2020 at 00:30)</a>:</h4>
<p>When people talk about "WASM as a VM" they usually mean WASM outside of a web browser and without JavaScript. If you are interested in that, I think <a href="https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/">Lin Clark's introduction to the Bytecode Alliance</a> is probably the best place to start! The only correction I'd make to that post is put <a href="https://wasmer.io/">wasmer</a> at the top of the list of WASM runtimes, as it has since become the primary non-browser WASM runtime everywhere.</p>



<a name="210080564"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210080564" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sam Sartor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210080564">(Sep 15 2020 at 00:53)</a>:</h4>
<p>Emscripten is really what makes this whole thing confusing. Originally it was a C -&gt; JS transpiler which implemented system APIs (e.g. OpenGL, the filesystem, stdout) by calling out to browser APIs (e.g. WebGL, IndexDB, console.log). But later that got turned upside-down. The idea was that instead of compiling your C (and later Rust) functions to JS, you should compile them into a bytecode format called WASM so they could be called by any language <em>including JS</em>, running on any platform <em>including the Web</em>. As a result, even now that emscripen is simply a clang wrapper, JS is WASM's oldest and closest friend. But they aren't <em>fundamentally</em> related. Just as JS program can run WASM files using a browser-provided VM, there are WASM runtimes for Go, Python,  Ruby, PHP, C, C++, C#, etc., and Rust. After that it wasn't long before someone wrote <a href="https://docs.wasmer.io/ecosystem/wasmer/usage">a Java-like command-line program</a> which uses one those runtimes to load a WASM module, grant it access to the user's system, and call "main".</p>



<a name="210082610"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210082610" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sam Sartor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210082610">(Sep 15 2020 at 01:35)</a>:</h4>
<p>FYI, emscripten not supporting general networking really has nothing to do with a limitation of wasm. How you give a wasm module network access depends a lot of the context. The specific context emscripten is designed for (C/C++ in a web browser) simply lacks a clear version of networking to emulate. For contrast, when you compile for the web a project which uses Rust's <code>reqwest</code> crate, <code>reqwest</code> uses the <code>wasm-bindgen</code> tool to autogenerate JS glue code to expose AJAX requests into the resulting WASM module. <a href="https://wasm.fastlylabs.com/">Fastly's serverless wasm VMs</a> have a more bespoke API for HTTP  access. And the web assembly system interface is <a href="https://github.com/WebAssembly/WASI/issues/315">currently working on a standard way to access raw network sockets</a> outside the browser which could be used by std/tokio/etc.</p>



<a name="210138743"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210138743" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210138743">(Sep 15 2020 at 14:42)</a>:</h4>
<p>...? Lots of people use <a href="https://github.com/bytecodealliance/wasmtime/">wasmtime</a> just fine, and it's of special interest to Rust because wasmtime is the one with Cranelift's backend. It's odd to say they aren't fundamentally related, because they have a very similar execution model. "You can use WASM to call out to other languages" isn't special, Node's been doing that for years. "You can use WASM to run other languages" is not special either, people have been doing some <em>really weird</em> things with JS for a long time. (what is special is, y'know, doing it efficiently... THAT is the only thing that's all that new. SIMD WASM and/or threaded WASM will be interesting as they will probably be the first major actual capability extension beyond JS.)</p>
<p>All the things you've mentioned are in fact fundamental limitations of WASM: it is, by design, an execution model for pure calculation without built-in IO, that must request additional resources in order to do IO. That is, a WASM runtime is, essentially, complete without the ability to do IO... in the JS context, that's provided by the browser's Web APIs, which are called out to, and are very much _not_ part of JavaScript but rather browser engine calls. The fact that it can be sandboxed and forced to go through what amounts to syscalls to the execution engine, rather than implicitly requiring them to even execute, is in fact a feature of the language, not a bug, not an accident, and not a mere add-on.</p>



<a name="210151583"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210151583" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210151583">(Sep 15 2020 at 16:16)</a>:</h4>
<p><span class="user-mention" data-user-id="222520">@Sam Sartor</span> wasmer is only "top" in their own minds and their own press; their primary feature is the aggression with which they push it. They're not nice people, and certainly not up to the standards expected by folks coming from the Rust community. (Ethical issues, openly attacking people, etc.)</p>



<a name="210158571"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210158571" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210158571">(Sep 15 2020 at 17:08)</a>:</h4>
<p>fwiw, I don't base my statements that "WebAssembly is a lot like JS" on a random idea:<br>
<a href="https://webassembly.org/docs/high-level-goals/">https://webassembly.org/docs/high-level-goals/</a><br>
All of the high-level design goals for WASM are literally "operate like JS, except as a compilation target."  In particular:</p>
<blockquote>
<p>execute in the same semantic universe as JavaScript;</p>
</blockquote>
<p>kills dead any assertion that it's not related to JS... it literally is meant to have seamless interop, and it does so by executing in the same context.</p>
<p><a href="https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations">https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations</a> documents how</p>
<blockquote>
<p>WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import. Such considerations are an embedder’s responsibility and the subject of API definitions for a specific environment.</p>
</blockquote>
<p>This is consistent with the JS "there is JS, and then there are Web APIs" model. JS, conceptually, does not include a single one of the <em>very commonly used</em> Browser APIs. Those are all the browser, and things it provides like the DOM. I liken it to syscalls because if you are not from the webdev world, that is the other near equivalent.</p>



<a name="210171430"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210171430" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sam Sartor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210171430">(Sep 15 2020 at 18:41)</a>:</h4>
<p><span class="user-mention" data-user-id="239881">@Josh Triplett</span> Thanks for sharing that! I switched over from wasmtime a while back because of feature differences &amp; language supoort. So I may have fallen for their press a bit. I look into them a bit more closely now.</p>



<a name="210173332"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210173332" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sam Sartor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210173332">(Sep 15 2020 at 18:55)</a>:</h4>
<p>@Jubilee You are totally correct. I should have clarified that although WASM and JS share very similar goals, even the same execution model &amp; and lack of standard APIs as you say, the two aren't <em>tied together</em>. You can use one without the other. I wanted to make sure @ender understood given he seems to be looking more into the non-web, non-node, non-V8/SpiderMonkey case.</p>
<p>However, I am going to continue to blame emscripeten for its own networking issues here. Yes wasm ships without network sockets but it ships without <em>anything</em>. Wasm-ifying any network primative is still perfectly possible with the right bindings &amp; runtime support. It would be even if WASI didn't exist. My day job is emscripten-fiddling so I can say from experience that its binding model is very limited in comparison to Rust's.</p>
<p>Finally, maybe the wasmer people are assholes, I'm looking into the drama now. But they do use the cranelift backend.</p>



<a name="210173648"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210173648" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210173648">(Sep 15 2020 at 18:57)</a>:</h4>
<p>Oh, yes. They're relatives as in siblings, they aren't required to stand in the same room.<br>
And yeah, Emscripten is... weird.</p>



<a name="210174559"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210174559" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210174559">(Sep 15 2020 at 19:04)</a>:</h4>
<p>The web only provides primitives for http requests (with many limitations), websockets and webrtc. Emscripten however targets POSIX, which only has sockets that you can send bytes over. POSIX doesn't have any api to make http requests, Adding internet support to emscripten would effectively require parsing the raw http requests created by the application (http/1.1, http/2, http/3) and format http responses to send back to the application.</p>



<a name="210175177"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210175177" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sam Sartor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210175177">(Sep 15 2020 at 19:08)</a>:</h4>
<p>They do have a hacky websocket-&gt;proxy way to support POSIX sockets but yah, its not a super great solution. They could do something different in node but if they do it isn't documented. I only use emscripten in the web so I don't know for sure.</p>



<a name="210175659"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210175659" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sam Sartor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210175659">(Sep 15 2020 at 19:12)</a>:</h4>
<p>I admit, we just do all our networking JS side and pass it over since the C++ libraries we would otherwise use for http (mainly libcurl) don't work in a wasm environment in they way, for example, reqwest does.</p>



<a name="210176901"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210176901" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sam Sartor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210176901">(Sep 15 2020 at 19:21)</a>:</h4>
<p>But if you were trying to set up a wasm VM like what Fastly is doing, you could ffi-in support for whatever networking you would like.</p>



<a name="210317234"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210317234" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> ender <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210317234">(Sep 16 2020 at 20:36)</a>:</h4>
<p><span class="user-mention silent" data-user-id="222520">Sam Sartor</span> <a href="#narrow/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking/near/210176901">said</a>:</p>
<blockquote>
<p>But if you were trying to set up a wasm VM like what Fastly is doing, you could ffi-in support for whatever networking you would like.</p>
</blockquote>
<p>What is ffi?</p>



<a name="210320272"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210320272" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sam Sartor <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210320272">(Sep 16 2020 at 21:03)</a>:</h4>
<p>@ender FFI is short for Foreign Function Interface. In this case I mean that your wasm module would make network requests by calling some <code>unsafe extern "C"</code> functions provided by the host. Wasm-bindgen is, in principle, capable of producing safer + higher-level bindings using interface types. <a href="https://github.com/bytecodealliance/wasmtime/issues/677">But that feature probably isn't ready yet to support something like this in practice.</a></p>



<a name="210320283"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/rust%20%3C-%3E%20wasm%20%3C-%3E%20VM%20networking/near/210320283" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/rust.20.3C-.3E.20wasm.20.3C-.3E.20VM.20networking.html#210320283">(Sep 16 2020 at 21:03)</a>:</h4>
<p><span class="user-mention" data-user-id="341972">@ender</span> "Foreign Function Interface" - calling things from one language in another language. (In the context of Rust, commonly calling C from Rust or vice versa.)</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>